home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000084_rts _Tue Apr 20 21:50:41 1993.msg < prev    next >
Internet Message Format  |  1996-01-31  |  5KB
  1. Received: from boojum.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP
  2.     id AA03754; Tue, 20 Apr 1993 21:50:42 MST
  3. Date: Tue, 20 Apr 1993 21:50:41 MST
  4. From: "Rick Snodgrass" <rts>
  5. Message-Id: <199304210450.AA19123@boojum.cs.arizona.edu>
  6. Received: by boojum.cs.arizona.edu; Tue, 20 Apr 1993 21:50:41 MST
  7. To: tsql@cs.arizona.edu
  8. Subject: benchmark schema and instance
  9.  
  10. There has been remarkably little traffic on the tsql mailing list
  11. concerning "key" and "groupness" in the benchmark. Given that the
  12. workshop is less than two months away, it is imperative that we
  13. finalize the schema and the instance, achieve consensus on the
  14. taxonomy, and move on to actually listing the queries.
  15.  
  16. Let me attempt to summarize the state of the discussion. Jim and
  17. Christian, if I have misinterpreted anything, please let me know.
  18.  
  19. A. The database instance should accord with ALL AND ONLY those
  20. constraints which are explicitly stated.
  21.  
  22. One constraint held by the data that was not stated was that the keys
  23. were time invariant. Christian mentioned two other such constraints:
  24. future information was not included and continuously varying
  25. attributes weren't included. One can envision all sorts of implicit
  26. constraints that are present in the data: the cardinality of the Name
  27. attribute must be two; salaries must be monotonically increasing;
  28. employees must not return to previous departments; no skills can be
  29. shared by two employees, etc. I don't believe a specific instance can
  30. satisfy all and only a (finite) set of stated constraints.
  31.  
  32. B. The term "key" as used may be defined as "at all times t, the
  33. attribute is a key of the snapshot of the relation at time t".
  34.  
  35. This is my rephrasing of Jim's stated definition. There seems to be
  36. consensus on this definition of the term "key".
  37.  
  38. C. Keys in the instance are time-invariant.
  39.  
  40. This is certainly true in the current instance. Christian lists four
  41. different alternatives, one being retaining this constraint in the
  42. instance, and making it explicit. Jim advocates dropping this
  43. constraint and modifying the instance by allowing *ED* to change his
  44. name on 1/1/88 to "Edward".
  45.  
  46. D. Grouped models have some very nice properties with regard to
  47. updating and querying.
  48.  
  49. Jim's description of the saga of *ED* is the best I've seen on why
  50. grouped models are so nice. If and when they are supported by temporal
  51. query languages, many advantages would accrue. Jim's argument is that
  52. we should drop the time-invariant constraint on keys in the benchmark
  53. instance to allow these nice properties to be demonstrated.
  54.  
  55. There are, however, some disadvantages to dropping this constraint.
  56.  
  57. 1. It makes the instance more complicated, though only marginally so.
  58.  
  59. 2. Quoting from Jim's book chapter (p. 532), "we did not find here,
  60. nor are we aware of, *any* complete algebra for grouped historical
  61. data models." I personally have some doubts that a complete algebra
  62. that is also efficient is even possible.
  63.  
  64. 3.  The only calculus I (Rick) am aware of that is grouped complete is
  65. the L_h calculus with which grouped completeness is defined. If this
  66. is true, then no current SQL or Quel-based temporal language will be
  67. able to demonstrate the advantages of grouping on the proposed
  68. instance. Whether a reasonable SQL extension that is grouped complete
  69. is possible is not known.
  70.  
  71. 4. As Christian has noted, and as Jim's analysis of simulating
  72. grouping in an ungrouped model shows, grouping relies heavily on the
  73. notion of surrogate. Such a notion is entirely absent from SQL2.
  74. Doing surrogates right in my opinion leads one to an identity-based
  75. model, as opposed to SQL2's value-based model.
  76.  
  77. I advocate being quite focussed, and not trying to do everything at
  78. once, either in the benchmark or in the initial SQL2 design.  The
  79. benchmark is to be used to evaluate proposed extensions to SQL2.
  80. Aspects that require nontemporal extensions to SQL2 may be very
  81. attractive, but are not within the purview of this initial effort, in
  82. my opinion. For example, an extension that requires recursive queries,
  83. or that requires subclassing, takes us far afield.
  84.  
  85. Making the change to the instance of allowing time-varying keys would
  86. invalidate all current approaches to SQL-based query language design.
  87. Such a change may in the long run be exactly the right way to go, but
  88. it cannot at this point in time be considered to be part of existing
  89. infrastructure. There are simply too many unanswered questions, and
  90. too great an incompatibility with SQL2.
  91.  
  92. In conclusion, I strongly advocate leaving the instance as is, and
  93. stating explicitly the constraint that keys be time-invariant in this
  94. schema. I also encourage further research into grouping, so that its
  95. many apparent advantages can be later incorporated into a consensus
  96. query language.